My perception here is that this additional option and/or the rational behind it isn't well understood by the WG or the editors/authors of this document. Nor does there seem to be much interest in perusing it. I understand that doing a PR was suggested to help facilitate discussion. But I would humbly suggest that a PR that adds oneself as an author and breaks the document build process is not a great way to solicit engagement.

Hi Brian, Thanks for your feedback. I apologize for the build failures. I'll try to get them fixed.

I tried the build from a couple of different machines but it doesn't seem to work for me, including just building a fresh clone of https://github.com/ietf-wg-wimse/draft-ietf-wimse-s2s-protocol.git . I'll see if I can figure out the problem, as of now I consistently get a failure from a package called kramdown-rfc, which I am not familiar with. I've attached one of the outputs from a Mac, but I got a similar failure with the same module from a Debian linux machine. I tried following https://github.com/martinthomson/i-d-template/blob/main/doc/SETUP.md.

failures.txt

@bc-pi @kenmccracken-google The build process is broken due to the linter picking up trailing spaces on two lines (see below). I ran make fix-lint and was able to build the PR locally, if this is to be included this would need to be fixed before merge:

[jricher@Boudica ~/Projects/draft-ietf-wimse-s2s-protocol (mtls-workload-proof*) ]$ git diff
diff --git a/draft-ietf-wimse-s2s-protocol.md b/draft-ietf-wimse-s2s-protocol.md
index a2df4e1..0824754 100644
--- a/draft-ietf-wimse-s2s-protocol.md
+++ b/draft-ietf-wimse-s2s-protocol.md
@@ -176,13 +176,13 @@ While the URI encoding rules allow host names to be specified as IP addresses, I
 
 As noted in the Introduction, for many deployments communication between workloads cannot use
 end-to-end TLS. For these deployment styles, this document proposes application-level protections.
-For deployments using end-to-end TLS, application-level credentials may be used to enrich the 
+For deployments using end-to-end TLS, application-level credentials may be used to enrich the
 application security context.
 
 The current version of the document includes three alternatives, all using the newly introduced
 Workload Identity Token ({{to-wit}}). The first alternative ({{dpop-esque-auth}}) is inspired by the OAuth DPoP specification.
 The second alternative ({{http-sig-auth}}) is based on the HTTP Message Signatures RFC. The third
-alternative ({{transport-layer-pop}}) is based on the TLS 1.3 and Token Binding RFCs. 
+alternative ({{transport-layer-pop}}) is based on the TLS 1.3 and Token Binding RFCs.
 We present the alternatives and expect
 the working group to select those that should progress towards IETF consensus.
 A comparison of the first two alternatives is attempted in {{app-level-comparison}}.

And now back to the matter at hand. Following Ken's post to the mailing list I think I understand the motivation somewhat better, but I still don't think this is a good idea.

The WIT is not an access token. It's a signed token that incorporates workload-specific information (mainly the workload's ID and its public key, but potentially future extensions) and therefore it should normally only be shared between a workload and its immediate neighbors (its successors on the call chain). As such, there are two options:

• The next hop is protected with MTLS (implicitly, there is no middlebox to break TLS security): no need for WIT because the identity information and public key are provided in the certificate.
• The next hop is not protected with MTLS but rather with server-authenticated TLS (and potentially a middlebox): we send the WIT over the network hop, and bind it to a signature or proof-of-possession.

So I don't see a reason to combine the WIT with MTLS.

By the way, the WIT is "authenticated" - it is signed by a trusted party, the server that issued it.

I think it's important to allow for an architecture for Service to Service Authentication that utilizes mTLS streams established using X.509 Certificate credentials.

| The WIT is not an access token. It's a signed token that incorporates workload-specific information (mainly the workload's ID and its public key, but potentially future extensions) and therefore it should normally only be shared between a workload and its immediate neighbors (its successors on the call chain).

I understood the WIT to be a Workload Identity Token. I agree it should contain the identity of the workload, represented by a URI, in the "sub" claim. When it comes to proof-of-possession semantics under RFC 7800, Section 3.1, I think the "cnf" claim should be used to identify the proof-of-possession key.

In this context, I think that referencing an X.509 Certificate (that contains the Workload's public key) using "x5t#S256" should be an option for "cnf", as an alternative to inlining the public key in the "jwk" member.

| As such, there are two options:
|
| The next hop is protected with MTLS (implicitly, there is no middlebox to break TLS security): no need for WIT because the identity information and public key are provided in the certificate.
| The next hop is not protected with MTLS but rather with server-authenticated TLS (and potentially a middlebox): we send the WIT over the network hop, and bind it to a signature or proof-of-possession.

I think from this description you would classify a proxy as a middlebox. I think the middlebox proxy may be capable of hop-to-hop mTLS. In this case, we would have the additional option:

• next hop is protected with mTLS, and is a middlebox. The middlebox is a proxy that forwards requests to destination workloads over mTLS.

In this architecture, the middlebox must perform proof-of-possession verification of the Workload's private key. The Workload-Identity-Token header can be forwarded intact to the destination Workload. The destination Workload verifies the identity of the middlebox over mTLS.

| By the way, the WIT is "authenticated" - it is signed by a trusted party, the server that issued it.

Agree, I think I wasn't clear in my wording. You're correct, the WIT is signed by the issuer. I probably should have said something like:

I think the Identity Server should issue WITs with a confirmation claim indicating the Workload's public key. I think recipients of the WIT should require proof-of-possession of the Workload's private key, according to the information in the "cnf" claim. I think the document should support verifying the proof-of-possession of the Workload's private key via one of

1. WPT, as described in [1] Section 4.2.
2. HTTP Message signatures, as described in [1] Section 4.3.
3. mTLS, as described in [3].

When the Identity Server puts an "x5t#S256" value in the "cnf" claim, the proof-of-posession verification method follows the semantics of RFC 8705, Section 3.1.

[1] https://datatracker.ietf.org/doc/draft-ietf-wimse-s2s-protocol/01/
[2] https://datatracker.ietf.org/meeting/121/materials/minutes-121-wimse-01
[3] #76